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GENERIC APPLICATION PROGRAM INTERFACE FOR NATIVE DRIVERS 

FIELD OF THE INVENTION 
5 [001] The present invention relates to the fields of information, computer 

software systems, and computer networks. In particular, embodiments of the present 
invention provide a generic application program interface for native drivers. 

BACKGROUND 

1 0 [002] In general, a computer application uses an application programming 

interface (API) that provide API functionality specific to the peripheral devices 
accessible to the computer on which the application runs. As such, the application may 
be configured with API functions to receive and send data readable by the specific 
peripheral devices and to access device-specific implementations of peripheral features, 

1 5 e.g., printing, scanning, etc. The application API may readily cause the native drivers 
installed on the computer to execute and control the peripheral devices. This 
configuration advantageously provides an efficient operation for the application on this 
computer. 

20 [003] However, the application in that same form typically may not use those 

same API functions to access a similar feature on a different peripheral device. Nor may 
the application be ported to another computer for use with its peripheral devices. This is 
because the device-specific implementations of the peripheral features of the different or 
new peripheral devices are unrecognizable and incompatible with the application. 

25 Hence, the application is unable to access the native drivers of these peripheral devices. 
Therefore, in order to access the different or new peripheral devices, the application must 
undergo significant modification in order to add the device-specific functionality of these 
devices. This requires significant time and labor for a system developer. 

30 [004] With the emergence of large computer networks having computers with a 

plurality of operating systems and a variety of peripheral devices that provide the same, 
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like, or different features, the current approach to application and API design is 
impractical. No system can afford the time and expense of providing related applications 
with APIs dependent on device-specific features for each and every permutation of the 
computers and their peripheral devices in the network. 

5 

[005] Accordingly, there is a need in the art for a generic device-independent 

solution that may commonly be used among multiple applications and computers to 
access device-dependent features through the corresponding native drivers of the 
peripheral devices. 

10 

SUMMARY OF INVENTION 

[006] Embodiments of the present invention provide a method for accessing 

native drivers in a computer using a generic application programming interface. The 
method may include providing the generic application programming interface to access 
1 5 multiple peripheral devices, where the interface is independent of the specific features of 
the peripheral devices. The method may further include using the interface to call 
generic routines as a function of specific features of a particular device in order to access 
the particular device upon receiving a request. 

20 [007] Embodiments of the present invention also provide a system upon which 

the generic application programming interface may be implemented. The system may 
include at least one peripheral device having a native driver associated therewith and a 
computer having the generic application interface. The computer may be configured to 
provide the interface to an application to access the peripheral device, independent of the 

25 specific features of the device. 

BRIEF DESCRIPTION OF DRAWINGS 

[008] FIG. 1 is an overview of a system according to embodiments of the 

present invention. 

30 . 
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[009] FIG. 2 is a diagram of a computer according to embodiments of the 

present invention. 

[0010] FIG. 3 is a diagram of an implementation of the generic native driver API 

5 according to embodiments of the present invention. 

[0011] FIG. 4 is a class diagram of an exemplary implementation of the generic 

native driver API. 

1 0 [0012] FIG. 5 is a flowchart of an embodiment of a method executing the generic 

native driver API. 

[0013] FIG. 6 is a diagram of an exemplary computer for implementing 

embodiments of the present invention. 

15 

DETAILED DESCRIPTION 

[0014] Embodiments of the present invention provide a method and system using 

a generic application programming interface (API) for native drivers to access peripheral 
devices. The generic API is able to support any device-specific implementation of a 

20 particular feature, e.g., printing, scanning, etc., on a peripheral device and cause its native 
driver to execute, independent of the particular feature of device. Thus, applications 
based on the generic API can be ported to different computers and used with different 
peripheral devices without modification. Accordingly, embodiments of the generic API 
of the present invention advantageously offer a device-independent access mechanism for 

25 applications to access the device-specific features on the peripheral device through the 
device's native driver. 

[0015] Embodiments of the generic API further provide a great deal of flexibility 

such that many different types of peripheral devices can be represented in the generic 
30 API. Additionally, new features may be implemented with minimal or no disruption of 
the overall API framework. 
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[0016] FIG. 1 is an overview of a system according to embodiments of the 

present invention. The system may include one or more computers 1 10, which may be a 
desktop, a laptop, a handheld device, or any like device having a processor therein. The 
5 system may further include one or more peripheral devices 120 in communication with 
the computers 1 10. The peripheral devices 120 may include a printer, a scanner, an 
imager, a smart card reader, a USB port, or any like I/O device. The computers 1 10 may 
access the peripheral devices via a local area or wide area network 130, a wireless link 
140, a direct connection 150, or any like transmission media. 

10 

[0017] FIG. 2 is a diagram of the computer 1 10 on which embodiments of the 

generic API may be implemented. The computer 1 10 may include an operating system 
(OS) 210, one or more applications 220, and the generic API 230. The application 220 
may use the generic API 230 to command performance of some procedure by the 
1 5 operating system 2 1 0. The generic API 230 may in turn direct the operating system 2 1 0 
to perform some procedure for the application 220. The operating system 210 may then 
control the allocation and usage of computer resources to carry out the application's 220 
request. 

20 [0018] In embodiments of the present invention, the application 220 may request 

through the generic API 230 that a particular peripheral feature be performed. Upon 
receiving the request, the generic API 230 may then direct the operating system 210 to 
access a particular peripheral device 120 to provide the requested feature. The operating 
system 210 may then cause the native driver associated with the particular device 120 to 

25 be executed, thereby providing the requested feature to the application 220, including 
receiving and sending data therebetween. As illustrated here, the application need not be 
dependent on the device-specific implementation of the requested feature. Instead, the 
application may request the feature in the abstract. To which, the generic API may direct 
access to the particular device through the device's native driver to provide a device- 

30 specific solution, where the solution may include generic routines commonly shared by 
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peripheral devices that are called as a function of the device-specific features a particular 
peripheral device. 

[0019] FIG. 3 is a diagram of an implementation of the generic API. In this 

5 embodiment, the computer 1 10 may include one or more applications 220, the generic 
API 230, and peripheral device native drivers 310. The application 220 may be in 
communication with the generic API 230 and the generic API 230 may be in 
communication with the native drivers 310. The native drivers 3 10 may in turn be in 
communication with the peripheral devices 120. Communication between the computer 
10 110 and the peripheral devices 1 20 may be accomplished via a direct connection, a 
wireless link, a network, or any like transmission media. 

[0020] As illustrated by FIG. 3, during implementation of embodiments of the 

present invention, one of the running applications 220 may send out a request to access a 

1 5 printer in order to print a document, for example. Peripheral device 120-N may be a 
printer. Accordingly, the generic API 230 may receive the print request, identify 
peripheral device N 120-N as the printer, call routines for printing from peripheral device 
N 120-N based on the parameters, configuration, etc., of peripheral device N 120-N, and 
then cause native driver N 3 1 0-N to execute in order to control peripheral device N 120- 

20 N. Upon access to peripheral device N 120-N, the application 220 may then transmit the 
data to be printed and peripheral device N 1 20-N may print it. 

[0021] The generic API may be implemented with an object-oriented approach. 

An advantage of such an approach is that it provides efficient, self-contained entities to 

25 define the peripheral devices and group the complex details of their many features and 
options. The objects implemented by the generic API allows the API to group together 
complex features of each peripheral device into a small number of data structures such 
that the API may easily control the peripheral features. Additionally, the use of objects 
allows the API to group together features that are common to all the peripheral devices 

30 such that a developer need not reproduce representations of the same feature for each 
device and the computer need not store redundant representations. Additionally, upon 
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implementation of new features for an existing device or an entirely new device, the 
generic API need not be disturbed greatly, but modification limited to particular entities. 

[0022] It is to be understood that the generic API of the present invention is not 

5 limited to the object-oriented implementation described herein, but may be implemented 
in a variety of ways well known in the art. 

[0023] Such an object-oriented implementation is illustrated in FIG. 4. FIG. 4 is 

a class diagram of an exemplary implementation of the generic API. The generic API 

10 may operate such that similar features on different peripheral devices 120 are accessible 
through common methods. In embodiments of the present invention, the generic API 230 
may receive a request from an application 220 to receive or send data to a particular 
peripheral device 120. The API 230 may then define a peripheral connection class which 
includes all the interfaces and classes that outline the basic functionality common to all 

15 the peripheral devices 120. The API 230 may then instantiate the peripheral connection 
class for the particular device 120 requested by the application. The instantiated 
peripheral connection class may in turn instantiate its classes and interfaces to include 
information specific to a particular device 120. The object created by the instantiation 
may then cause the native driver for the particular device 120 to be executed in order to 

20 communicate the application's 220 request to the device 120 and, therefore, control the 
device 120. 

[0024] The peripheral connection class and its associated interfaces and classes 

are described as follows. The peripheral connection class 410 is the central class of the 
25 API. The peripheral connection class 410 may include a connection interface 420, a 

parameter interface 430, a connect data interface 440, an event listener interface 450, and 
an event interface 460. When the peripheral connection class is instantiated, the 
instantiated class includes the information specific to the requested peripheral device 120. 
The functionality of each of these components will be described below. 

30 
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[0025] The connection interface 420 may outline the basic connection routines 

commonly used by all the peripheral devices 120. The connection interface 420 may 
include an input connection interface 422 and an output connection interface 424. The 
input interface 422 may outline the basic routines to be used to receive data from the 
5 peripheral device 120, including executing the native driver associated with a particular 
peripheral device 120 and performing data translation to make the data compatible with 
the requesting application 220. The output interface 424 may outline the basic routines to 
be used to send data to the peripheral device 120, including executing the native driver 
associated with a particular peripheral device 120 and performing data translation to 
10 make the data compatible with the peripheral device 120. The input and output interfaces 
422, 424 may include a serial connection interface 426, which outlines the basic routines 
for serially connecting to the peripheral device 120, and a parallel connection interface 
428, which outlines the basic routines for parallel connection to the peripheral device 
120. 



15 



20 



[0026] When the peripheral connection class 4 1 0 is instantiated, the connection 

interface, the input interface, the output interface, the serial interface, and the parallel 
interface are implemented to include those routines for connecting to the requested 
peripheral device 120. 



[0027] The parameter interface 430 may outline the basic routines to be used to 

define the configuration parameters of the peripheral devices 120. The routines may 
include attribute classes 432 that define the complex attributes having many options of 
the peripheral devices 120. For example, a font associated with printer data may be 

25 represented by an attribute class that defines the font parameters, such as size, bold, 

italics, spacing, etc. When the API specifies a particular font to be used by a printer, an 
instance of the font class representing the requested font and its parameters may be 
passed to the printer. The attribute classes 432 advantageously allow a developer to add 
to the API additional classes corresponding to new options for a particular peripheral 

30 device 120 without affecting any application that accesses the attribute classes prior to 
the addition of the new options. 
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[0028] When the peripheral connection class 4 10 is instantiated, the attribute 

classes are instantiated to define the attributes of the requested peripheral device 120. 
The parameter interface is implemented to include those routines for configuring the 
5 requested peripheral device 120 based on the instantiated attribute classes. 

[0029] The connect data interface 440 may outline the basic routines to be used to 

retrieve data from the peripheral device 120. The routines of the connect data interface 
440 may include instructions and data structures for retrieving and storing data from a 

10 peripheral device 120. For example, the connect data interface implemented for a 

scanner may include a routine to get a barcode read by the scanner and store the barcode 
in a data record. The routines of the connect data interface 440 may also access the 
attributes classes 432 to identify the data attributes and communicate the attributes to the 
requesting application 220. For example, the connect data interface implemented for a 

1 5 scanner may use the instantiated attribute class to identify the barcode byte length and 
then communicate the length to the requesting application. 

[0030] When the peripheral connection class 41 0 is instantiated, the connect data 

interface is implemented to include retrieval and storage routines for the requested 
20 peripheral device 120. 

[0031] The event interface 450 may outline the basic routines for managing 

asynchronous input, i.e., requests. Asynchronous input may include events that are 
triggered by an application or a peripheral device. In an alternate embodiment, an event 
25 may be triggered by a user, another device, etc. In this embodiment, exemplary events 
may include a connect event, in which an application 220 requests access to the 
peripheral device 120, a disconnect event, in which an application 220 requests 
termination of access to the peripheral device 120, and a data event, in which the 
peripheral device 120 has data available for transmission to an application 220. 

30 
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[0032] When the peripheral connection class 4 1 0 is instantiated, the event 

interface is implemented to include routines that manage asynchronous inputs involving 
the requested peripheral device 120. 

5 [0033] The event listener interface 460 may outline the basic routines for calling 

an application when a data event occurs. When the peripheral connection class 410 is 
instantiated, the event listener interface is implemented to include routines to call the 
requesting application when a data event occurs in the requested peripheral device 120. 
The routines include an implementation of the connect data interface 440 to retrieve the 
1 0 data from the peripheral device 120. 

[0034] The peripheral connection class may access a computer attributes class 

470 which provides diagnostic information about the computer 1 10 on which the API is 
installed. The computer attributes class 470 may provide identifying information about 
15 the model of the computer 110 and the peripheral devices 120 currently accessible to the 
API. The API may access the computer attributes class 470 to ensure that the peripheral 
device requested by the application is part of the API. 

[0035] When the generic API is initialized, the computer attributes class may be 

20 instantiated to provide the attributes of the computer 1 1 0 running the API. 

[0036] The peripheral connection class may also access a bridge interface 480, 

e.g., a Java™ Native Interface (JNI), to provide a bridge between the generic API and 
routines written in other programming languages. For example, the bridge interface 480 

25 may provide a bridge between the generic API and the peripheral device drivers 410 and 
other external applications. The bridge interface 480 may ensure that each peripheral 
device 120 only has one active access from the applications on the API. As such, the API 
may provide to an application exclusive access to the peripheral device 120. If a second 
application tries to establish a connection to the peripheral device, the API may generate 

30 an error message. In an alternate embodiment, if a peripheral device 120 supports 
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simultaneous access by separate applications, then the API may allow for this because the 
connection parameters of the peripheral device 120 will include this capability. 

[0037] When the generic API is initialized, the bridge interface may be 

5 implemented to provide a bridge between the generic API and external software with 
which the generic API will interact. 

[0038] FIG. 5 is a flowchart of a method according to an embodiment of the 

present invention. The API may receive (505) a request (or event) regarding a peripheral 
1 0 device. The API may then check (5 1 0) whether the peripheral device is accessible and 
the appropriate routines are installed on the computer. 

[0039] If the check is not successful, the API may issue an error message. If the 

check is successful, then the API may determine (515) the nature of the request. 

15 

[0040] If the request is an application's request to access a peripheral device, then 

the API may instantiate (520) the peripheral connection class and its interfaces associated 
with the requested peripheral device. The object created by instantiation may then cause 
(525) the native driver of the requested peripheral device to execute and control the 
20 peripheral device. The API may then send (530) data to the requested peripheral device 
in order for the device to perform the application's request. 

[0041] If the request is a peripheral device's request to transmit data to an 

application, then the API may notify the application (535) that data is available from the 

25 peripheral device. The API may then instantiate (540) the peripheral connection class 
and its interfaces associated with the peripheral device. The object created by 
instantiation may then cause (545) the native driver of the peripheral device to execute 
and control the peripheral device. The API may then collect (550) the data from the 
peripheral device using the implemented connect data interface and send the data to the 

30 application. 
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[0042] If the request is an application's request to terminate access to a peripheral 

device, then the object of the existing instantiated peripheral connection class may cause 
(555) the native driver of the peripheral device to execute and disconnect the peripheral 
device. The API may then uninstantiate (560) the peripheral connection class, thereby 
5 deleting the object. 

[0043] FIG. 6 is a block diagram of an exemplary computer that can implement 

embodiments of the present invention. The computer 1 10 may access peripheral devices 
according to embodiments of the present invention. The computer 1 1 0 may include, but 

1 0 is not limited to, a processor 620 provided in communication with a system memory 
module 630, a storage device 640, and an I/O device 650. The processor 620 may 
execute the generic API, applications, and the operating system. The memory 630 may 
store program instructions to be executed by the processor 620 and also may store 
variable data generated pursuant to program execution. In practice, the memory 630 may 

15 be a memory system including one or more electrical, magnetic, or optical memory 

devices. The I/O device 650 may include a communication port for communication with 
the peripheral devices 120 to receive and transmit data between the peripheral devices 
120 and the computer 1 10. 

20 [0044] Prior to real-time operation of the generic API in the computer 1 1 0, the 

API may be tested using an emulator that simulates interaction with the peripheral 
devices 120. The .emulator may allow a developer to tests all execution paths in the 
applications that would be used in real-time to access the peripheral devices 120. The 
emulator may also allow the developer to set up simulations of one or more peripheral 

25 devices, in which the behavior and attributes of the peripheral devices may be configured. 
After the devices are configured in the emulator, the developer may trigger peripheral 
data input to the application via an emulator display window, for example. The 
application may then process the data as it would for the real peripheral device. 

30 [0045] In an alternate embodiment, the API may provide functionality allowing 

selection of a subset of the peripheral devices accessible by a particular application or a 
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particular computer. The embodiment may provide a selection wizard that allows the 
developer to select the subset of devices. In one embodiment, the selection wizard may 
be implemented as a web-based user interface tool that guides the developer through a 
series of prompts until the subset of devices is selected. Accordingly, the drivers for the 
5 selected devices may be deployed to the computer for future access by the generic API. 

[0046] It may be understood that the structure of the software used to implement 

the embodiments of the invention may take any desired form, such as a single or multiple 
programs. It may be further understood that the method of an embodiment of the present 
1 0 invention may be implemented by software, hardware, or a combination thereof. 

[0047] The above is a detailed discussion of the preferred embodiments of the 

invention. The full scope of the invention to which applicants are entitled is defined by 
the claims hereinafter. It is intended that the scope of the claims may cover other 
1 5 embodiments than those described above and their equivalents. 
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